home *** CD-ROM | disk | FTP | other *** search
/ Qoole for Quake / Qoole for Quake (USA) / Qoole for Quake (USA).bin / Tutorial / HTML / QUBE.ZIP / README.ID < prev    next >
Encoding:
Text File  |  1996-11-05  |  5.3 KB  |  100 lines

  1. This is the source for the three utilties that a .map file passes through
  2. before it becomes a finished .bsp file.  I went through 28 iterations of
  3. the output format, and eight major rewrites of the code during the
  4. development, so there are probably a few code skeletons lying around.
  5.  
  6. I have compiled this code on nextstep, digital unix, irix, and nt, so it
  7. should be easily portable to any environment you choose.  The digital unix
  8. version is multi-threaded to run on SMP systems.  The NT version has not
  9. been tested very well.
  10.  
  11. qbsp : this does the CSG operations on the brushes, fills away the outside
  12.        of the map, generates a bsp and all of the polygons required for
  13.        drawing, bsps for the clipping hulls, and copies all of the textures
  14.        that are actually used out of the editor's wadfiles into the output
  15.        bsp files.  In hindsight, I wish I had split this program up a little
  16.        more.  There is an awful lot of code in it.
  17.  
  18.     qbsp can generate these files:
  19.  
  20.     map.bsp    - the output map file to be read by quake or light / vis
  21.     map.prt    - the portal file to be read by vis
  22.     map.h1
  23.     map.h2       - hull files written by forked processes.  Can be safely
  24.              deleted.
  25.     map.pts    - pointfile for tracing leaks in the level.    In quake,
  26.              you can type "pointfile" and it will leave a trail of
  27.              dots from the outside to the first entity it ran into.
  28.              Qbsp will refuse to generate a .prt file if the map is
  29.              not completely sealed in. It is possible to vis an
  30.              unsealed map, but it could take hours. Seal it up first.
  31.  
  32. light : this takes the .bsp file generated by qbsp and does light casting
  33.     from all of the light objects in the map.  Normally, it takes one
  34.     light sample for each lightmap point, but the "-extra" parameter
  35.     causes it to take four samples (and four times as long to run) and
  36.     average them.  The lighting model used has little theoretical
  37.     grounding (it has linear fallof, for instance), it was just tweaked
  38.     until it looked good.
  39.  
  40. vis : this takes the .prt file generated by qbsp, along with the .bsp file,
  41.       and generates a compressed bit array of the potentially visible set of
  42.       each leaf.  This can take a very long time, depending on the input
  43.       data.  The time is related to the number of portals off of each leaf.
  44.       A simple wolfenstein like level would have leafs with an average of
  45.       only two portals from each leaf, and would vis very fast.  The worst
  46.       case for vising would be a stadium environment, where you have a huge
  47.       area with lots of things sticking out of the ground but not contacting
  48.       other major occluders.  A single large room like that can take more
  49.       time to process than an entire level made up of more densly occluded
  50.       areas.
  51.  
  52. These utilities are very processor intensive.  Here at id, we share a four
  53. processor alpha 4/275 for all map processing.  The final levels in quake
  54. take about 15-20 minutes each to fully process, which means that on a
  55. pentium 90 it would probably take about 2 1/2 hours.  Obviously not something
  56. you want to do very often.
  57.  
  58. You can make a .bsp file that can be run by quake with just the qbsp program.
  59. When it is loaded into the game, it will be fullbright, and will allways draw
  60. the entire level (slow).  This is fine for developing small tests, but
  61. different methodologies are required for developing full size levels.
  62.  
  63. Our map editor lets us region an active work area, so construction is usually
  64. done a couple rooms at a time, allowing qbsp + light to be done quickly, and
  65. not requiring a vis at all.
  66.  
  67. Once a level has been completed, entities (monsters, items, etc) can be moved
  68. or changed without reprocessing the entire level by running qbsp with the
  69. -onlyents parameter.  This does not work for doors, triggers, etc that are
  70. composed of brushes.  One of these days I will get around to coding that...
  71.  
  72. Our map editor also has a "relight" option, which does a qbsp -onlyents, then
  73. a light, while still leaving the vis information intact.
  74.  
  75. There are opportunities for network level parallization with some recoding.
  76. Qbsp uses fork level parallization to utilize up to three processors, and it
  77. would be trivial to change to allow it to be run on three computers.  Light is
  78. embarassingly parallel, and can be divided arbitrarily.  Vis is highly parallel,
  79. but it takes some advantage of order of completion in the serial case, so
  80. scaling is not quite linear.
  81.  
  82. There are certainly major algorithmic optimzations that can be made to the
  83. code to improve the processing speed.
  84.  
  85. The vis speed for bad cases could be improved dramatically by growing together
  86. leafs that have large numbers of portals into larger psuedo-leafs.
  87.  
  88. The ray casting method I used in light is of debatable speed for the normal
  89. sampling level, but at the -extra sampling level it would almost certainly be
  90. faster to process an entire view from each light, rather than each light to each
  91. sample point.  That would be a total rewrite, though, not a simple patch.
  92.  
  93. I use doubles everywhere in these programs.  At one point this was necessary to
  94. avoid some problems, but I tightened up the numerics in the program since then,
  95. and it may not be needed any more. I don't recall the change being a huge speed
  96. lose, in any case.
  97.  
  98. John Carmack
  99. Id Software
  100.